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In functional programming, monads are supposed to encapsulate computations, effectfully produc- 
ing the final result, but keeping to themselves the means of acquiring it. For various reasons, we 
sometimes want to reveal the internals of a computation. To make that possible, in this paper we in- 
troduce monad transformers that add the ability to automatically accumulate observations about the 
course of execution as an effect. We discover that if we treat the resulting trace as the actual result 
of the computation, we can find new functionaUty in existing monads, notably when working with 
non-terminating computations. 

1 Introduction 

Consider a simple database in which different users store data under keys. This can be represented in 
Haskell as a data structure of type [ ( User, [ {Key, Data) ])]. We can define a function getData which looks 
up a value for a specified user and a key. 

getData :: [{User, [{Key, Data)])] — t- User — t- Key — t- Maybe Data 
getData db uk = lookup u db ^>3= lookup k 

If a user u has an entry d associated with a key k in the database, getData u k returns Just d; otherwise, 
it returns Nothing. In the latter case we might want to inform the user 'why' the program is not able 
to deliver data: they might have misspelled their username, which means that lookup u will fail, or they 
might have tried to read from a missing key, which means that lookup k will fail. Unfortunately, the 
Maybe monad does not allow one to observe at what point a failing program actually fails. We need to 
structure our function using a more sophisticated monad. 

What are the desired properties of such a monad? For sure, we want it to employ the same kind 
of effects as Maybe, so that we do not have to alter the logic of our program. We would like to have 
a lift operation, which allows us to automatically translate some operations from Maybe into the new 
monad, so that it is not necessary to rewrite standard functions like lookup. But most importantly, it must 
also reveal some observations about the course of execution (a trace), such as the number of successful 
subcomputations, from which we can extract the desired information about the point of failure. One 
possibility is to explicitly accumulate such observations inside the computation, using monads like Writer 
or Exception. In this article, however, we take a different approach: we automate the accumulation inside 
the monadic structure. The accumulation is transparent inside the computation; that is, it cannot affect 
the course of execution, and is revealed only on the outside. 

We aim for maximum genericity: we construct transformers that add traces to arbitrary monads. Our 
main tools are free monads (Section|2]), which have the ability to represent the very structure of monadic 
computations. They provide, in a sense, the most informative traces possible. Then, we introduce a 
transformer, called Nest, which allows one to mix the free and effectful computations provided by a 
monad (Section [3]l. The genericity pays off, and we find a number of applications for tracing monads: 
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Traces of computations can be interpreted in different ways. In Section 4.3 we show an example 
in which, by revealing the inner structure of a computation in the List monad, we can define the 
Prolog cut operator. 

Computations encapsulated in monadic expressions are often monolithic. They are supposed to 
produce final values only, so there is little space for non-termination. But, assuming non-strict 
semantics, we can see computations as entities that lazily unfold a trace. So, even if a computation 
is non-terminating, we can benefit from its infinite trace. If we interpret free parts of a Nest value 
as terms, we discover that Nest is a generalisation of Capretta's partiality monad (see Section 4. 1 1. 

For the same reasons, traces are a useful tool for modelling impure interaction with the environ- 
ment. In Section [6} we sketch out some future work on a novel, coinductive approach to the 
functional semantics of effects. 



2 Simple tracing with free monads 

Moggi |[T9l called monads notions of computation, because they describe computational effects in a way 
that abstracts from the type of values produced by a computation. In a sense, from the categorical point 
of view, monads abstract even from the exact values produced by the computation, since return and join 
are natural transformations. It is the bind operator (defined as m =join (fmapf m)) that mixes the 
functorial (looking only at the vahxe?,) finap and parametric (looking only at the structure) join. The laws 
for monads and functors entail the following equality, called naturality of join. 

fmapfojoin =joinofmap (finapf) 

Read as a transformation from left to right, it allows one to move occurrences of join to the left of a 
composition, and occurrences of jmap to the right. This way, we can split computations with multiple 
steps into a "mapping" part and a "joining" part. For example, consider a computation m »=/ »=g. It 
can be split as follows. 

m ;;S3=/ :^3=g = (Join ofmap g ojoin o fmapf) m = (join ojoin ofmap (fmap g) o fmapf) m 

Intuitively, we can see the "mapping" part (that is, fmap (fmap g) ofmap f) as the construction of the 
computation and the "joining" part {join ojoin) as the execution of effects. 

Our first approach to tracing is to capture the mapping part of a computation. We suspend execution 
of the join operators of the monad, so that we can isolate and examine the elements from which the 
computation is composed. 

2.1 Free monads 

The type of the mapping part is different for different numbers of nested occurrences of the fmap function, 
and so for computations consisting of different numbers of steps. For example. 

Just ' a ' : : Maybe Char 

fmap Just (Just 'a') : : Maybe (Maybe Char) 

fmap (fmap Just) (fmap Just (Just ' a' )) :: Maybe (Maybe (Maybe Char)) 

A reasonable class of datatypes in which to store such expressions are the free monads, also known as 
f -generated trees. Allowing ourselves to define monads in terms of fmap, return, and join, rather than 
the return and required by Haskell, we can write: 
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data Freef a = Wrap if {Freef a)) \ Return a 

instance Functor f =^ Functor {Freef) where 
fmap g (Return a) = Return (g a) 
finap g (Wrapf) = Wrap (fmap (fmap g)f) 

instance Functor f =^ Monad (Freef) where 
return = Return 

join (Return f) =f 

join (Wrapf) = Wrap (fmap joinf) 

Each level of the type constructor of a monad corresponds to a level in the Free data structure. We store 
Just 'a' :: Maybe Char as Wrap (Just (Return 'a')), and Just (Just ('a')) :: Maybe (Maybe Char) as 
Wrap (Just (Wrap (Just (Return 'a')))), and so on. 

2.2 Monad transformers with drop 

The type Free m a can be seen as a datatype of terms generated by the signature m (a functor) and a set of 
variables a. Even if m is a monad, Free m cannot depend on any effects provided by m; the join operation 
for Free m performs only substitution, and is independent of the join for m. 

In order to couple a monad m and the m-generated free monad, we need the notion of monad trans- 
formers |[T6ll . A monad transformer with drop is a relation between two monads, m and t, characterised 
by two functions, lift and drop, which translate computations in m into computations in t, and vice versa. 
The relationship can be defined as the following two-parameter Haskell type class. Though in functional 
programming drop is rarely considered to be a member of MonadTrans, it plays an important role here. 
For the moment, we forget that we usually insist that monad transformers are subject to a certain set of 
algebraic laws. 

class (Monad m, Monad t) =^ MonadTrans mt\t ^ m where 
lift y.ma^ta 
dropwta -^ma 

For any monad m, we define an instance of MonadTrans m (Free m) as follows. The lift operation is 
straightforward, as it only wraps the value and maps the Return constructor. The drop operation traverses 
the structure and flattens each level, thus performing suspended bind?, of m. 

instance (Functor m, Monad m) =^ MonadTrans m (Free m) where 
lift = Wrap ofmap Return 

drop (Return a) = return a 
drop (Wrap m) =m »= drop 

2.3 Examples 

Now, we can test our tracing free monad transformer on the Maybe monad. The lift function allows us to 
translate any computation in m into a computation in Free m. To get the original, non-traced computation 
back, we use the drop function. 

We can see every composition Wrap o Just as a "tick", given for each lifted successful subcomputa- 
tion. The trace forms a unary counter, storing the number of ticks. The final value of the computation is 
stored in the last Wrap. Consider the following conversation with the Haskell interactive shell. 
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> do { lift {Just 2) ; lift {Just 4) ; lift Nothing } 
Wrap {Just {Wrap {Just {Wrap Nothing)))) 

> drop (do { lift {Just 2); lift {Just 4) ; lift Nothing } ) 
Nothing 

Similarly, for the Writer monad, we can get a list of all the values appended to the monoid followed by 
the final return value. (For brevity, we show Writer {a, Sum s) as {s,a).) 

i> do { lift {tell {Sum 2)); lift {tell {Sum 3)); lift {tell {Sum 7)); return ' a' } 
Wrap {2,Wrap {3,Wrap {1, Return 'a'))) 

> drop (do {lift {tell {Sum 2)); lift {tell {Sum 3)); lift {tell {Sum 7)); return ' a' }) 
(12, 'a') 

An important thing to notice is that non-terminating computations in Writer do not make much sense. 
For example, the following computation just diverges. 

i> let w n = do { tell {Sum n); w (« + !)} in wO 
(*** Exception: stack overflow 

In contrast, with the tracing version of Writer, we can enjoy an infinite stream of actions that happen 
during the execution: 

> let w « = do {lift {tell {Sum n)); w (n + 1) } in w 

Wrap (0, Wrap {\,Wrap (2, Wrap (3, Wrap (4, Wrap (5, Wrap (6, Wrap (7, Wrap (8, Wrap. . . 



3 More advanced tracing with free structures 

Tracing computations with free structures is not very flexible: every bind and every join is suspended, 
creating a new level of structure every time a monadic action is called. In some circumstances we would 
like to trace only selected parts of the computation — perhaps we are confident that the other parts always 
succeed, or we want to treat selected pieces of the computation monolithically, and we are not interested 
in a fine-grained report about their behaviour. 

Another issue is the algebraic properties of monad transformers with drop. Intuitively, a pair of 
monads m and t are related as a monad transformer if t incorporates at least the same effects as m. This 
is usually formalised with the following equalities [12]. 

lift {return a) = return a 

lift {m >:=/) = lift m {lift of) 

drop {return a) = return a 

drop {lift m ^£3=/) = m ^>3= drop of 

The first two equalities state that lift is a monad morphism. The instance MonadTrans m {Free m) 



from Section 2.2 does not have this property. For example, lift {Just 1) ::>> lift {Just 2) is equal to 
Wrap {Just {Wrap {Just {Return 2)))), while lift {Just 1 y> Just 2) is equal to Wrap {Just {Return 2)). 

For these two reasons, we abandon the idea of using free monads directly to trace computations. 
Instead, in this section we introduce a general class, MonadTrace, which allows one to specify the points 
at which to make observations about the execution, and a corresponding version of the Free monad that 
is a proper monad transformer. 
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3.1 The MonadTrace class 

The MonadTrace class introduces a single monadic value, mark. Intuitively, this is an operation that 
stores the current state of execution in the trace. 

class Monad t MonadTrace t where 
mark:: t () 

We call a monad v a tracer of a monad m, if m and v form a monad transformer (MonadTrans m v), and 
V is an instance of MonadTrace. Additionally, lift, drop and mark should satisfy the following equaUties. 

lift {return a) = return a 

lift (m»=/) = lift m'::^^ {lift of) 

drop {return a) = return a 

drop (v g) = drop v {drop o g) 

drop mark = return () 

The tracer v cannot perform more effects than the monad m, except for tracing with the mark operation. 
Nonetheless, tracing does not affect the course of computation in any way observable from inside of the 
v-computation, hence both lift and drop are monad morphisms. Note that the laws entail drop o lift = id. 

We use the mark gadget wherever we want to make an observation. In the following example, the 
intuitive semantics of a tracer for the Maybe monad is that we get a tick whenever the computation is 
still successful when placing a mark. 

do {x lift niQ; y ■ir- lift m\ ; mark; z ^ lift m2', mark; return {x+y + £)} 

That means that if mo is successful, but m\ fails, no ticks are stored in the trace (intuitively, it is equivalent 
to Nothing). Only if both mo and m\ are successful, the mark operation stores this success (the trace is 
of the form Just a, where a is a result of the rest of the computation). If m2 is also successful, the 
second call to mark stores this information in the trace (and the trace is of the form Just {Just a), where 
a = return {x + y + z) = Just {x+y + z))- 

We also define a convenient function, mind, to perform a traced lifting. 

mind :: {MonadTrans m v, MonadTrace v) ^ ma^v a 
mind m = Ao{x-<r- lift m; mark; return x} 

Then the previous example can be written more concisely: 

do {x ■<— mo; y^^mindmy, z-^mindm2; return {x + y + z}} 

3.2 The Nest monad 

Free monads allow one to capture the structure of an m-computation as data; but for tracing, we need 
also to be able to perform some parts of the computations (the lifted ones) immediately. This suggests 
considering the composition of the two monads m and Free m, in one order or the other. In fact, because 
we want the hfted parts to be performed immediately, the appropriate order of composition is to have m 
on the outside and Free m inside. We therefore define: 
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newtype Nest ma = Nest{ unNest : : m [Free ma)} 

instance Functor m =^ Functor {Nest m) where 
fmapf (Nest m) = Nest (finap (fmapf) m) 



It remains to show that Nest can be given the structure of a monad. We do this using Jones and 
Duponcheel's prod construction |fT4l: given monad M with unit retuniM and multiplication jo/n^, and 
similarly monad F with return f and joinp, the composition M F forms a monad with unit and multipli- 
cation given by 

Diagrammatically: 

return f 



M prod 

MFMF > MMF 



return = returnM o return f 
join = join^f ofmapj^ prod 



returnm F 



join 



MF 



join„ F 



MF 



provided that natural transformation prod :: F M F ^ M F satisfies the three properties 

prod o return f = id (1) 
prod ofmapp return = return/^ (2) 
prod o finap p join = join o prod (3) 

Diagrammatically: 



return F MF 

MF > FMF 



^ F return 

F > FMF 





returnM F 



prod MF 

FMFMF > MFMF 



F join 



FMF 



prod 



join 

MF 



(In fact, the multiplication 70 of F is not used; all that is required of F is for it to be a premonad.) It 
turns out that the definition of prod is — if not quite forced then at least — very strongly suggested by the 
necessity of satisfying these three properties. 

In our case, M is the monad m, and F is the datatype Free m from Section [2] For brevity, let us 
write M forfinapf^, and similarly F for jhiapp; let us also write the coproduct type former as + and the 
coproduct moiphism as V, so that we can express the two constructors as one composite, 

WrapV ReturnwM F +1 -> F 

and name its inverse, 



outpwF ^ M F +\ 



Recall that the unit of the monad Free m is the constructor Return: 



retump = Return 



Without loss of generality, we let 
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prod o [Wrap V Return) = prod^ V prod2 

so that 

prodi = prod o Wrap 
prod2 = prod o Return 

The definition of prod2 is forced: 

prod2 

= { definition of prod2 } 

prod o Return 
= { F as a premonad: retump = Return } 

prod o return f 
= { property (1) } 

id 

Now consider property (2). Expanding the left-hand side, we have 

prod o F return 
= { datatype isomorphism } 

prod o F return o {Wrap V Return) o outp 
= { naturality of Wrap V Return } 

prodo (Wrap V Return) o [M F return + return) o outp 
= { definitions of prod^ , prod2 } 

[prodi V prod2) o (M F return + return) o outp 
= { coproducts } 

{{prodi oM F return) V {prod2 o return)) o outp 

and for the right-hand side we have 

returuM 
= { datatype isomorphism } 

returnM o (Wrap V Return) o outp 
= { coproducts } 

{{returnM ° Wrap) V {returnM o Return)) o outf 

These two expressions must be equal, which impUes that the equaUties 

prodi oM F return = returnM ° Wrap 
prod2 o return = returnM o Return 

must hold. The second equality follows from prod2 = id and the definition of return; we'll use the first 
one to derive a definition for prodi • We have: 

prodi °M F return 
= { (A) suppose that prodi = prod'i o M prod } 

prod'i o M prod oM F return 
= { functors } 
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prod\ o M {prod o F return) 
= {(B) induction } 

prod\ oM returriM 
= { (C) suppose that prod\ = returriM o Wrap o joinf^ } 

returriM o Wrap ojoinf^oM returnM 
= { M is a monad } 

returriM o Wrap 

and so property (2) strongly suggests letting 

prod I = returriM o Wrap ojoiriMoM prod 

The three steps (A), (B), (C) need a little justification. For (A), we're heading towards a use of induction, 
so we require an occurrence of M prod at the end of prod^. For (B), induction seems plausible, because 
this calculation takes places under a Wrap constructor. For (C), the final M returriM is cancellable via 
joiriM, so we're done — we let be prod\ be the final expression we want composed with this cancellation. 

We don't need any stronger justification for induction than mere plausibility, because we are using 
this calculation only to suggest a possible definition of prod^ that we should then check more rigorously. 
This still leaves us also with having to check property (3), again by induction. Both of these proofs are 



presented in Appendix A 



The final instance declaration for Nest is then as follows: 

instance {Functor m, Monad m) =^ Monad {Nest m) where 
return = Nest o retuniM o Return 

join = Nest ojoinM ofmapM prod o unNest 
where 

prod {Return {Nest m)) =m 

prod {Wrap m) = {returnM o Wrap ojoinM °f^'^PM P^od) m 



3.3 Tracing with Nest 

For any monad m, the monad Nest m is a tracer. The lift function maps Return on values. It does not 
create any Wrap constructor, so lifted computations are single-level and are always joined when join 
for Nest is performed. The drop function traverses the free structure, and collapses levels which were 
previously separated by Wrap constructors. The mark gadget explicitly creates a new level by the Wrap 
constructor mapped on Returns. All future computations will be confined to the wrapped Returns, and 
so the previous structure is preserved. 

instance {Functor m, Monad m) =^ MonadTrans m {Nest m) where 
lift = Nest ofmap Return 
drop V = unNest v revert 
where 

revert {Return a) = return a 
revert {Wrap m) =m revert 

instance {Functor m, Monad m) =^ MonadTrace {Nest m) where 
mark = {Nest o return o Wrap o return o Return) () 
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The proof that these definitions satisfy the laws of MonadTrace from Section 3.1 is given in [Appendix B 



As an example of mark, consider the following conversation with the Haskell shell. The call of the 
mark operation in the second query maps Wrap on every element. This way, every future computation 
is confined to the inside of those two Wrap constructors. Whatever monadic computation is bound to 
the result, on the top-level there will always be a two-element list, because it is a node with only Wrap 
constructors as children. 



>lift[\,2] 

Nest [Return \ , Return 2] 

t> do {x^ lift [1,2]; Uft[0..x]} 

Nest [Return 0, Return I, Return 0, Return \ , Return 2] 

>do {lift [1,2]; mark} 

Nest [Wrap [Return {)],Wrap [Return ()]] 

i>do {x lift [1,2]; mark; lift [0. .x] } 

Nest [Wrap [Return 0, Return I], Wrap [Return 0, Return \,Return2]] 



4 Interpreting traces 

The tracing construction has multiple applications. As in the motivating example from the introduction, 
we can track the course of computation, in order to identify any point of failure. But, stepping back from 
this particular example, we observe that a trace is simply a data structure, and the computation in the 
Nest monad is performed only if the data structure is forced. This gives us control over the process of 
execution, which can be useful in the context of non-terminating computations (although the inductive 
proofs will need strengthening in that context). We can interpret the free parts of a Nest value in any way 
we want, and thus mix in some new effects, not previously available with the original monad. This control 
over a computation from the outside strongly resembles the paradigm of aspect-oriented programming. 

4.1 The partiality monad 

Capretta introduced the partiality monad IS to capture non-termination as an effect; this technique has 
applications in type theory, to model non-guarded recursion. The original formulation is as follows. 

data Partial a = Later (Partial a) \ Now a 

A structure of this type is a value wrapped in a (possibly infinite) number of Later constructors. It 
represents a computation sliced into layers. We can explicitly force any number of layers. The Nest 
monad can be seen as a monad transformer which allows computations structured by any monad to be 
sliced. The most basic case. Nest Identity, is indeed isomorphic to Partial. 

In most programming languages, including Haskell, the V operator is asymmetric — non-strict in its 
second argument (True V _L = True) but strict in its first (_L V True = _L). In pure Haskell, it is impossible 
to define parallel-or — that is, a disjunction Y with the property that True Y _L = True = _L Y True. 

To implement such a disjunction in the real world, we need some kind of parallelism, so that both 
arguments are evaluated simultaneously; when either one terminates with True or both terminate with 
False, the computation of the disjunction is complete. We can purely approximate this behaviour — at 
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least for the case where undefined arguments arise from non-termination, rather than from any other 
reason. We do this by explicitly cutting the infinite computation into finite pieces, using the Nest tracer. 

Consider the following function, which is an implementation of the so-called CoUatz problem. It is 
suspected that for all n > it returns True, but no proof for this claim is known. 

collatz "Integer — )• Bool 
collatz 1 = True 

collatz n I odd n = collatz (3 x « + 1) 
I otherwise = collatz {n 2) 

If we want to check whether at least one of two Collatz sequences ends, it is not the best idea to use the 
regular Haskell disjunction, since if the first one diverges, the whole function diverges too. 

oneOf : : Integer — )• Integer — )• Bool 
oneOf a b = collatz a V collatz b 

A much safer solution is to chop the evaluation of the Collatz sequence into pieces. We use the Nest 
tracer for the Identity monad. This way, we make the evaluation incremental, which enables us to execute 
it in parallel. The scheduler is very simple and hidden in the definition of T. It executes a piece from 
each argument in turn. 

collatzN '.'.Integer — t- Nest Identity Bool 
collatzN 1 = return True 

collatzN n \ odd n = mark ^ collatzN (3 x n + 1 ) 
I otherwise = mark y-> collatzN {n 2) 

( Y) : : Nest Identity Bool — )• Nest Identity Bool — ?• Bool 
Nest {Identity (Leaf False)) Y Nest {Identity {Leaf False)) = False 
Nest {Identity {Leaf True)) Y _ = True 

_ Y Nest {Identity {Leaf True)) = True 

Nest {Identity {Node m)) Y x = xY Nest m 

We can test the Y operator as follows. Note that collatz diverges if applied to 0. 

collatzN 120 Y collatzN 130 
True 

> collatzN Y collatzN 130 
True 

> collatzN 130 Y collatzN 
True 

This model can easily be extended to different kinds of such thread races. For example, it is possible to 
simulate McCarthy's ambiguous choice operator amb wa^b ^ Either a b [T8|, which has the property 
that for aa'.'.a and bo'.'.b, amb ao _L = Leftao, and amb _L bo = Right bo (again, assuming that the undefined 
values arise from non-termination). 
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4.2 Approximating computations 

For some monads, the initial segment of a Nest value may be seen as an "approximation" to the computa- 
tion. Consider the monad of finitely supported probability distributions. Its most common representation 
is a list of probabilities paired with values. 

newtype Distr a = Distr{ runDistr : : [ {Double, a)]} 

instance Functor Distr where 
finapf (Distr xs) = Distr (finap {X{p,d) — t- (p, f a)) xs) 

instance Monad Distr where 
return a = Distr [ ( 1 , a) ] 

join (Distr xs) = Distr [{p x q,a) \ {p, Distr ys) ^ xs, {q,a) ^ys] 

However, this representation has a flaw. Consider the following problem: given the uniform distribution 
of {0, 1} (a fair coin), select uniformly an element from {0, 1,2}. A solution is to flip the coin twice to 
get the uniform distribution of {0, 1,2,3}; if you draw 0, 1, or 2, this is your answer, and if you draw 3, 
flip twice more. In Haskell: 

coin '.'.Distr Int 

coin = Distr [(0.5,0), (0.5, 1)] 

third '.'.Distr Int 
third = Aox^ coin 
y •(— coin 
case {x,y) of 

(1,1)—)- return 
(1,0) — )• return 1 
(0, 1) — )• return 2 
(0,0) third 

(This is a simplification of Knuth and Yao's technique to simulate a fair die using three fair coin tosses 
ifTSl .) Though the solution is mathematically reasonable, the Haskell implementation is useless, because 
the List monad, and so also the Distr monad, gathers the results in a depth-first fashion. Though this may 
not be obvious at first sight, the recursive call in third is in the head of the list. Therefore, third actually 
diverges without producing any usable results: third = _L. 

The Nest monad can retrieve the situation, if we suspend the recursive call. 

thirdN : : Nest Distr Int 
thirdN = do x lift coin 
y ^ lift coin 
case {x,y) of 

(1,1) — )• return 
(1,0) — )• return 1 
(0, 1) — )• return 2 
(0, 0) — > mark » thirdN 

What can we do with thirdN? One possibility is to get an "approximation" of the structure with the 
following function, which cuts the subcomputations if the recursion is deeper than the specified argument. 
All the computations that are too deep are replaced with Nothing. 
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takeN : : (Functor m, Monad m) =^ Int Nest ma^ Nest m [Maybe a) 
takeN k [Nest m) = Nest ifinap {aux k) m) 
where 

aux {Wrap ) = Return Nothing 

aux k {Wrap m) = Wrap (fmap {aux {k—l))m) 
aux k {Return a) = Return {Just a) 

approx : : {Functor m, Monad m) =^ Int — > Nest ma^m {Maybe a) 
approx k = drop o takeN k 

We can ask the Haskell shell: 

> approx thirdN 

[{0.25, Nothing), {0.25, Just 2), {0.25, Just I), {0.25, Just 0)] 

t> let simpl {Distrxs) = Distr {map {Xx — >■ {sum \p\{p,a) xs,x = a],x)) {nub (fmap sndxs))) 

> simpl (approx 1 thirdN) 

[{0.0625, Nothing), (0.3125, Just 2), (0.3125, Just I), (0.3125, Just 0)] 

> simpl (approx 2 thirdN) 

[(0.0\5635, Nothing), (0.328l3,Just 2), (0.32Sl3,Just I), {0.328l3,Just 0)] 

> simpl (approx 10 thirdN) 

[(2.3S4l9e-l, Nothing), (0.33333, Just 2), (0.33333, Just I), (0. 33333, Just 0)] 
4.3 The Prolog cut operator 

Prolog's cut operator allows one to restrict backtracking. The moment it is reached during evaluation of 
a predicate, it succeeds, but also discards all the possible backtrack choices created by the predicate so 
far. By exposing the structure of a List computation, we can use this effect also in Haskell. We perform 
a depth-first search on a rose tree of type Nest [], but once we go down a level, we never go back. 

call:: Nest []a—^ [a] 
call (Nest xs) = aux xs 
where 

aux [] =[] 

aux (Return a : xs) = a : aux xs 

aux (Wrap as : _) = aux as 

brace : : Nest [ ] a — )• Nest [ ] a 
brace = lift o call 

cut:: Nest [] () 
cut = mark 

Consider the following example. 

t> call ( do x^ lift [4,7,13,9] 

y^lift[2,S,\] 

when (x+y ^ 15) cut 

return (x+y) ) 
[6,12,5,9,15] 
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(Here, when is a standard Haskell function, defined by when bm = iib then m else return ().) First, we 
pick 4 from the first list, which after choices from the second list creates [6, 12, 5]. Then, we pick 7 from 
the first list. We cut on the second element of the second choice (because 7 + 8 = 15). So, all the other 
choices from the second list (that is, 1) are discarded, as well as other choices from the first list (that is, 
13 and 9). 

We can limit the scope of cut by using the brace function. Only choices from inside of the brace are 
now cut. 

t> call {do lift [4,7,13,9] 

brace ( do y ^ Z/^ [2, 8, 1 ] 

when {x+y ^ 15) cut 

return {x+y) ) ) 
[6,12,5,9,15,15,11,17] 

Different interpretations of the Nest data structure enable the definition of different search strategies, 
such as breadth-first search. Moreover, it can even mix two different strategies in lifted and minded parts. 

4.4 Poor man's concurrency transformer, revisited 

Claessen's "poor man's" concurrency transformer Q adds simple concurrency capabilities to any monad. 
It has two flaws. The first one is that it does not respect the laws presented in Section |3] Every lifted 
operation is atomic, and execution can only be interrupted in between atomic actions; this means that the 
evaluation of lift ni\ ^ lift m2 can be interrupted by an action from another thread, while lift {mi » m2) 
cannot. The second flaw is that the return type of its run function is m (), and so it does not allow one to 
collect actual results of the computation. Here, we give a version of Claessen's transformer which fixes 
these flaws, via a conscious use of free structures. 

In Claessen's monad, the user first builds a continuation, which produces an expression, which then 
is interpreted by the run function. By augmenting the type of expressions, we can skip the continuation 
layer. The datatype for concurrent expressions is as follows. 

data Action ma= Par {Action m a) {Action m a) \ Act {m {Action ma))\ Done a \ Kill 

Intuitively, the Par constructor pairs two expressions for parallel evaluation. Act performs a single 
monadic action. Done terminates the computation with an answeiQ and Kill terminates the computa- 
tion with no answer. We treat Action as a term algebra with Done as a constructor for variables. 

instance Functor m =^ Monad {Action m) where 

return = Done 

Par a b >:=/ = Par {a >:=/) {b >:=/) 
Act m >:=/ = Act (fmap (»=/) m) 
Done a »=/ = f a 
Kill >:=/ = Kill 

The Action datatype describes a program, but does not specify which actions form atomic chunks 
that should not be interrupted by other operations. This task is delegated to the Nest transformer. The 



The Kill constructor is called Stop in Claessen's datatype, and Done is new. 
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type of our concurrent monad is then Nest {Action m) a, for a monad m and answer type a. We define 
a number of operations, wliicli allow easy construction of concurrent expressions. The functions done 
and kill lift the appropriate constructors. A single operation can be embedded in an Action data structure 
and lifted to the concurrent monad with act. There are two operators for concurrency, par and/orA:. The 
former constructs a computation from two computations of the same type. The latter starts an auxiliary 
thread, whose final value is ignored (see the examples below). 

type Concurrent m = Nest {Action m) 

done : : {Monad m) ^ a—^ Concurrent m a 
done = lift o Done 

kill:: {Monad m) =^ Concurrent m a 
kill = lift Kill 

act : : {Monad m) ^ma^ Concurrent m a 
act m = lift {Act {liftM Done m)) 

par:: {Monad m) =^ Concurrent ma ^ Concurrent ma ^ Concurrent m a 
par {Nest m\) {Nest mj) = Nest {Par {Done {Wrap m\)) {Done {Wrap wi))) 

fork :: {Monad m) =^ Concurrent mb ^ Concurrent m () 
fork m = par {m ^ kill) {act {return ())) 

We schedule such computations with the following round function. We can see Done as a constructor 
which either terminates evaluation of an atomic chunk (when it is composed with Wrap) or the entire 
thread (when it is composed with Return). 

round:: Monad m =^ [Nest {Action m) x] — > m [x] 
round [ ] = return [ ] 

round {Nest w : as) = case w of 
Kill — )• round as 

Done {Return x) — > do {xs ■<— round as; return {x : xs) } 
Done {Wrap a) — )■ round {as -H- [Nest a] ) 
Actm {a m; round {[Nest a]-\+ as)} 

Par ab — )■ round { [Nest b]^as+\- [Nest a ] ) 

We can test our monad as follows. In the first example, we first define two expressions: cat writes 
the string "cat" five times, relinquishing control every time the operation is performed. Similarly, ^^/i 
writes "fish" seven times. 

instance {Monoid s) =^ MonadWriter s {Concurrent {Writer s)) where 
tell = act o tell 

cat:: Concurrent {Writer String) Int 

cat = replicateM 5 {tell " cat " mark) return 1 

fish :: Concurrent {Writer String) Int 

fish = replicateM 7 {tell "f ish" ^ mark) ^ return 2 

We can test them, by running them in parallel. 

> round [do x ^ fish 'par' cat 
tell "dog" 
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return x] 

("catf ishcatf ishcatf ishcatf ishcatf ishdogf ishf ishdog", [1,2]) 

The results of all parallel threads called with par, in this example [1,2], are returned in a list. The 
operation tell "dog" is bound to both threads. 

We can now mn fish in a separate, auxiliary thread. The thread is run on the side, the following 
actions are not bound to it, and its result is not returned with the overall result. 

I> round [do fork fish 
X ^ cat 
tell "dog" 
return x] 

("catf ishcatf ishcatf ishcatf ishcatf ishdogf ishf ish", [1]) 

We can also define a version offish that is performed atomically. 

fish' v. Concurrent {Writer String) Int 

fish' = replicateM 1 {tell "fish") » return 2 

We can see that round does not separate the calls of tell "fish". 

> round [do fork fish' 
X ^ cat 
tell "dog" 
return x] 

("catf ishf ishf ishf ishf ishf ishf ishcat cat cat catdog", [1]) 



5 Related work 

The idea of separation of syntax and semantics of monadic computations is not new. It is the very foun- 
dation of the success of monads as a tool for encapsulating impure behaviour in pure languages [21 1 — for 
example, the way Haskell integrates impure effects such as I/O within a pure language is to make the 
pure evaluation construct a syntactic term, which is subsequently interpreted by the run-time system. 

The work most related to ours is the Unimo framework introduced by Lin fTT], which is an embedded 
domain-specific language designed to modularise construction of monads in Haskell. Even though Lin's 
motivation and toolbox significantly differ from ours, he came to the same conclusion that exposing the 
structure of computations allows more functionality to be added to existing monads. We share a strong 
flavour of aspect-oriented programming. 

There is a resemblance between resumptions, used for modelling semantics of concurrency lISlfTTl. 
and the Nest monad. A resumption monad transformer is used, for example, by Papaspyrou to model 
semantics of concurrency in domain theory 1201 . and by Harrison in his "cheap" concurrency ll9l [TOl. 
They both use a definition similar to ours from Section [2] (though they fail to mention the connection 
between free monads and resumptions), and as a result their constructions are not transformers in the 
sense of Section |3] 

Harrison Q is not quite right in claiming that Claessen's monad is based on first-class continuations. 
A version of the continuation monad is used only to build a syntactic term, which serves as the backbone 
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of the concurrent computation. The term is not a monad, since it lacks free variables, but it reveals the 
structure of resumptions (notice the type of the constructor Atom ::m {Action m) — )• Action m). Simi- 
larly, in Swierstra and Altenkirch's functional specification of concurrency |23|, resumptions are used 
implicitly, and control is surrendered by a thread whenever it wants to communicate with other parts 
of the concurrent system (which is denoted by a constructor of the free structure lOc)- As we show in 
Sections 4.1 and |4.4[ the Nest monad transformer allows one to separate the concepts of composition of 
computations and yielding, by an explicit use of mark. 

A definition of a resumption transformer, which satisfies the laws from Section [3] and is in fact iso- 
morphic to Nest, was already given by Cenciarelli and Moggi |4] , but practical applications in program- 
ming were not studied. Also — as pointed to us by the anonymous reviewers — the Nest transformer can 
be obtained via Hyland, Plotkin and Power's sum construction [ 13 1, as a sum of a monad and an Identity- 
generated free monad. Though Hyland et al.'s construction provides a simpler proof that Nest can be 
given a monad structure (using a distributive law between a monad m and the m-generated free monad), 
our definition of join is not intensionally similar to the one arising from the sum construction, and issues 
like efficiency should also be taken into account. A naive implementation of join in the sum construction 
traverses the structure twice (once to apply the distributive law, and once to join the free structure), while 
join for Nest needs to traverse the structure only once. On the other hand, the sum construction allows 
one to include an additional functor — the datatype in question is of the formM {Free {FoM) a) — which 
may help to generalize our notion of tracing in the future. 

The interleaving between pure data and monadic structure was also considered by Filinski and 
St0vring Q, and in forthcoming work by Atkey et al. [1]. They give proof principles for reasoning 
about datatypes that include effects, for example a stream in which tails are always guarded by I/O 
actions. 



6 Future work 

So far, we failed to mention the mother and father of all purely functional monads, that is the continuation 
and state monads. We do not have much to say about continuations, but we see a lot of applications in 
tracing the State monad. 



Functional specifications of effects. The idea behind functional specifications of effects in pure lan- 
guages is to model the logic of an effectful construct in the pure core of the language. For example, such 
a specification may consist of a datatype representing a model of the outside world and a variation of the 
State monad whose state modifications mirror the actions of the side-effecting monad. This way, we can 
translate a program into its pure equivalent, test it, and reason about it no differently from how we would 
reason about any other pure program. 

The existing frameworks for specifying "effectful" Haskell in "pure" Haskell — like those proposed 
by Swierstra and Altenkirch [22, 23] and Butterfield et al. ||2]|6| — do not concentrate on non-terminating 
computations, which are of little use in the pure world, but which are back in the spotlight in the pres- 
ence of effects like I/O and concurrency. For example, Butterfield et al. model the interaction between 
programs and a filesystem by means of the State monad, which for an initial state (of the filesystem) 
produces a final value and a final state. In case of non-terminating programs, no final state exists, so 
the whole model becomes useless. What we are really interested in is not a final state, but the whole 
(possibly infinite) sequence of subsequent states of the filesystem, or a trace of all the interactions. In 
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such a setting, we can use coinduction as a reasoning tool, which coincides with the non-strict semantics 
of Haskell, in which we try to embed our model. 

As mentioned before, our approach can transform monolithic computations into coinductive unfold- 
ing of traces. That is why we propose to use a different monad as a basis for functional specifications. It is 
a monad which produces not only the final state, but the whole (possibly infinite) stream of intermediate 
states. 

data Trace s a = TCons s [Trace s a)\ Nil a 

newtype States s a = State s{ runStates :: 5 — t- Trace s a} 

We leave the exact implementation of instances of Monad (States s), MonadTrans [State s) [States s) and 
MonadTrace [States s) to the reader as an exercise. The mark operation should accumulate the current 
state in the Trace. 

What is the relationship between States s and Nest [State s)l It is possible to interpret free parts of 
Nest [State s) in a suitable way, that is to define a monad morphism of type Nest [State s) — )■ States s. 
We can also suspect a different kind of generality, since State is a composition of two adjoint functors, 
namely State s = Reader s o Writer s, while States s = Reader s o Free [Writer s). 
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Appendix A Proof that Nest is a monad 



We prove the properties (2) and (3) from Section 3.2 by induction, assuming an initial-algebra reading 
of the datatype Free m — that is, we assume a well-founded ordering on the subterms of any value of type 
Free m a. (We have to resort to something like induction, because the definition of prod above isn't in 
the form of a standard recurson pattern — in particular, it is not a fold.) For brevity, we omit the Nest 
constructor. 

Property (2): The case for Return is straightforward. For the Wrap case, we assume that the property 
holds for each element of data structure m; that is, that 

M (prod o F return) m = M returnM m 

Then we calculate: 

{prod o F return) (Wrap m) 
= { naturality of Wrap ::M F ^ F } 

{prod o Wrap oM F return) m 
= { definition of prod } 

{returnM o Wrap ojoin^ ° M prod oM F return) m 
= { functors } 

{returnM ° Wrap ojoinM ° M {prod o F return)) m 
= { induction } 

{returnM ° Wrap ojoinM ° M returnM) m 
= { M as a monad } 

{returnM o Wrap) m 

Property (3): The case for Return is again straightforward. In the Wrap case, we again assume that 
the property holds for each element of m: 

M (join o prod) m = M (prod o F join) m 

Then we calculate: 

(join o prod) (Wrapm) 
= { definition of join } 

(joinj^^ o M prod o prod o Wrap) m 
= { definition of prod } 

(joinM o M prod o returnM ° Wrap o joinM ° M prod) m 
= { naturality of returnM } 

(joinM ° returnM o prod o Wrap ojoinM ° ^ prod) m 
= { M as a monad } 

(prod o Wrap o joinM ° M prod) m 
= { definition of prod } 

(returnM ° Wrap ojoinM ° M prod ojoinM ° ^ prod) m 
= { naturality of joinM } 

(returnM ° Wrap ojoinM ojoinM oM M prod o M prod) m 
= { M as a monad } 

(returnM ° Wrap ojoinM ° M joinM oM M prod o M prod) m 
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= { functors } 

{returuM o Wrap ojoiUf^oM {joinf^oM prod o prod)) m 
= { definition of join; induction } 

[returriM o Wrap o joiUf^ o M (prod o F join)) m 
= { functors } 

[returuM o Wrap ojoiUf^ o M prod o M F join) m 
= { definition of join } 

[re turn M o Wrap o join oM F join) m 
= { definition of prod } 

[prod o Wrap o M F join) m 
= { naturality of Wrap ::M F ^ F } 

{prod o F join) {Wrap m) 



Appendix B Proof that Nest is a tracer 



Here, we prove that Nest is a tracer (see Sections 3.1 and 3.3 for tlie definitions). The equaUties 
lift = id and drop mark = return {) are straightforward. 

We prove the equality lift o returnM = return^ as follows. 

liftoreturnM 
= { definition of lift } 

M Return o returnM 
= { naturality of retuniM } 

returnM ° Return 
= { definition of return } 

return!<{ 

The fact that lift c ys^N lift of = lift {c /) follows from the following. 

Uftc >:^N Uftof 
= { definition of »=Ar } 

;om^ {N {lift of) {Uftc)) 
= { definition of lift } 

joini^ {N {M Return of) {M Return c)) 
= { definition ofN} 

joinf^ {MF {M Returnof) {M Return c)) 
= { definition of join } 

joinM {M prod {MF {M Return of) {M Return c))) 
= { functor } 

joinM {M {prod o F {M Return of) o Return) c) 
= { definition of F } 

joinM {M {prod o Return o M Return of) c) 
= { definition of prod } 

joiriM {M {M Return of) c) 
= { naturality oi joinM } 
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(M Return ojoinM) {Mf c) 
= { definition of lift } 

lift ijoinM {M f c)) 
= { definition of joiuM } 

lift {c :^Mf) 

To prove the fact that drop is a monad morphism we first prove a lemma 
joiriM o M revert o prod o Ff = joiriM o joinm o MM revert o M/ o revert 
The case for Return follows from simple unfolding of the definitions. The case for Wrap is as follows. 

(joiriM o M revert o prod o Ff) ( Wrap m) 
= { definition of F } 

ijoinM °M revert o prod) {Wrap (MFf) m)) 
= { definition of prod } 

ijoinM ° M revert o returnM o Wrap o joinM ° M prod o MFf) m 
= { naturality of returnM } 

ijoinM o returnM o revert o Wrap o joinM ° M prod o MFf) m 
= { monad laws } 

[revert o Wrap o joinM ° M prod o MFf) m 
= { definition of revert } 

ijoinM o M revert o joinM ° M prod o MFf) m 
= { naturality of joinM } 

ijoinM o joinM ° MM revert o M prod o MF f) m 
= { monad laws } 

ijoinM o M joinM ° MM revert o M prod o MFf) ) m 
= { functor } 

ijoinM o M ijoinM o M revert o prod o Ff) ) m 
= { induction } 

ijoinM o M ijoinM o M joinM ° MM revert o Mf o revert) m 
= { functor } 

ijoinM o M joinM ° MM joinM ° MMM revert o MMf o M revert) m 
= { monad laws } 

ijoinM ojoinM ° MM joinM ° MMM revert o MMf o M revert) m 
= { naturality of joinM } 

ijoinM o M joinM ° join- m o MMM revert o MMf o M revert) m 
= { naturality of joinM } 

ijoinM o M joinM ° MM revert o joinM o MMf o M revert) m 
= { naturality of joinM } 

ijoinM ° joinM ° MM revert o Mf o joinM ° M revert) m 
= { definition of revert } 

ijoinM o joinM ° MM revert o Mf o revert) {Wrap m) 



To prove that drop (c ^=jv /) = drop c (drop of), for c:: a and / :: a — > Nest m b, we unfold the 

definition of (^s=) and prove the equivalent equaUty drop ijoinj^ {Nf c)) = joinM {M {drop of) drop c). 
It follows from the commutativity of the following diagram (in Hask). For brevity, we write /i^v for the 
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join of monad Nest. The left-most path of the diagram is equal to joiuM o M {drop of) o drop, while the 
right-most path is equal to drop o join^ o Nf. 



drop 



MFA 




MFA = 

M revert 

MMA 

MMf 



MMMFB 

MMM revert 

MMMMB 

MM revert Miw ^ M ^Im M 

Mdrop I MMMB MMMB 

Mum I^mm(^ ^Mum 

MMB MMB — 

MB ^=^= MB 



MFA = 

MFf 

MFMFB = 

Mprod 

MMFB = 



= MFA 

MFf 

= MFMFB 

Mprod 

= MMFB 1 M-v 



MM revert 

MMMB 



M^lM 



HmM 



MFB 



M revert 



\1 

MMB - 
MB = 



drop 



-MMB 
= MB 



The first column of the diagram depicts unfolding of the definitions of drop. The second column is equal 
to the first one due to the fact that joiriM is a natural transformation: the morphism joiriM ::MMA MA 
form the first column "travelled" down the path to settle as joiuM ::MMMB — )• MMB. Additionally, due 
to the monad law for joiriM, we can exchange MMjoiriM with MjoiriM- This allows us to use the lemma, 
the M-image of which commutes columns 2 and 3. Again, we can use the monad law to change MjoiriM 
into joiriM. We use the naturality of joiriM to switch its position with the mapping of revert, which justify 
the fourth column. 



